Not applicable.
Not applicable.
1. Field of the Invention
The present invention generally relates to a domain validation process for a bus (e.g., SCSI bus). More particularly, the invention relates to a domain validation process for a SCSI bus that is transparent to drivers associated with devices coupled to the bus. More particularly still, the invention relates to making a bus device driver aware of a state change of a device during a domain validation process that is transparent to the device driver.
2. Background of the Invention
Many types of electrical systems (e.g., computers) include a small computer system interface (xe2x80x9cSCSIxe2x80x9d) to which one or more peripheral devices attach. The SCSI bus is particularly well suited for tape drives, CD ROM drives, and the like. One of the features specified in the SCSI standards is that a SCSI-compliant device can include a memory device into which xe2x80x9csense dataxe2x80x9d can be stored. Such sense data includes a variety of information. In the context of a tape drive, the sense data may indicate xe2x80x9cend of tape,xe2x80x9d xe2x80x9crewind,xe2x80x9d etc. For a CD ROM drive, the sense data may indicate if the programmed block size associated with the disk has been changed.
A characteristic of the SCSI sense data is that it is generally only present in a SCSI device when a change has occurred only until the sense data is read by external logic such as a SCSI bus adapter. For example, a tape drive may have no sense data in its memory reserved for storing sense data. Then, when the end of tape condition occurs, the tape drive writes a value to the memory to indicate that the end of tape condition has occurred. That end of tape sense data remains in the tape drive""s memory until the SCSI adapter reads the sense data. The tape drive alerts the SCSI adapter that sense data is present and the adapter responds by reading the tape drive""s sense data. Once the sense data has been read, the tape drive clears the memory location in which the sense data was stored. Essentially, SCSI sense data is a xe2x80x9cread oncexe2x80x9d type of data.
The SCSI standard is a highly flexible standard that permits system designers to assemble together various disparate types of devices. Because of this flexibility, it is possible for designers and operators of computers with SCSI components to violate, intentionally or not, certain basic requirements. For instance, two 16 bit SCSI devices might be mistakenly interconnected by an 8 bit cable (referred to as a xe2x80x9cwidthxe2x80x9d problem). In this situation, an error will not necessarily be reported, but every other byte of data will be dropped. By way of another example, an 80 MB/sec bridge device might be disposed between two 160 MB/sec SCSI devices (referred to as a xe2x80x9cspeedxe2x80x9d problem). As such, the devices will not be able to correctly communicate at their full speed.
For problems such as those described above, the current version of the SCSI standard (xe2x80x9cSCSI-3xe2x80x9d) includes a provision for a xe2x80x9cdomain validationxe2x80x9d process. The domain validation process includes several tests that can be run. A basic test, for example, determines if the SCSI subsystem is capable of operating at a specified speed and width. Generally speaking, this test executes by sending a predetermined test pattern to a SCSI target device. Then, the target device is requested to return the test pattern and the returned test pattern is compared against the original pattern to ensure it is identical. The domain validation process is typically initiated during boot, and at other times by a specific user request. After a user changes a SCSI device or cable, for example, the user must request to run the domain validation process.
The SCSI-3 standard allows that the domain validation process be, if desired, transparent to the SCSI device drivers. When the domain validation process runs transparently, the device drivers are not involved in the performance of the test. A transparently run domain validation advantageously minimizes the complexity of the device drivers themselves and minimizes the performance impact on the system while running the domain validation.
Although a generally advantageous process, a transparently run domain validation process can result in a device driver being unaware of the current state of its device. This problem occurs when sense data becomes present during the domain validation process. For example, if a SCSI device or the entire SCSI bus is reset during the domain validation process or a tape reaches its end of tape condition during a domain validation process, such sense data will be made available in the effected devices. Such information will then be read by the SCSI adapter which is performing the domain validation process and then, as noted above, erased from the device. The SCSI adapter cannot pass the sense data on to the device""s driver because, in a transparently run domain validation process, the device driver has no involvement. Thus, with nothing else to do with the sense data, the SCSI adapter simply drops the sense data. This situation is typically referred to as xe2x80x9closing statexe2x80x9d because the adapter drops the information and the device itself erased the sense data after the adapter read it.
Most importantly, the device""s driver is unaware that its device had sense data. If that lost state was an end of tape condition, the driver will be unaware that the tape is at its logical end. For CD ROM drives, for example, another piece of logic in the system may change the block size associated with the CD ROM during the domain validation. The device driver associated with the CD ROM will be unaware of this change and thus be unable to accurately retrieve date from the CD.
solution to this problem is needed. Such a solution preferably would make it possible for a device driver to be made aware of a state change that occurred during a domain validation process that runs transparently with regard to the device driver.
The problems noted above are solved in large part by an electronic system, such as a computer, which includes a bus, such as a SCSI bus, for which domain validation processes can occur transparently (i.e., without device driver involvement). The preferred embodiment of the system includes a SCSI bus adapter which runs firmware to support the domain validation process. The adapter initiates the domain validation process with respect to the peripheral devices on the SCSI bus. If any one or more SCSI peripheral device reports the presence of sense data to the SCSI adapter, the adapter records that sense data in its memory, or at least records that sense data was reported by a peripheral device. Then, towards completion of the domain validation process, the bus adapter resets the entire bus, or alternatively, resets only those peripheral devices that actually reported the presence of sense data.
By resetting the bus, or a subset of devices, the devices"" device drivers will automatically be re-synchronized with their devices. The next time the device driver attempts to access the reset device, the device will report to the driver that it has been reset, in accordance with normal SCSI procedure. The driver will then initialize the device and, at that point, both the driver and its device will be synchronized (i.e., the driver will be accurately aware of the operational state of the device). In short, the reset during the domain validation process is used as a mechanism to cause the driver and device to again be synchronized following a change of state during a transparent domain validation of which the device driver would otherwise be unaware.
These and other advantages will become apparent upon reviewing the following disclosures.